home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / August 96 / Re Scripting Problem.3 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.3 KB  |  [TEXT/ttxt]
  1. Subject:     Re: Scripting Problem
  2. Sent:        8/6/96 11:03 AM
  3. Received:    8/6/96 10:21 AM
  4. From:        Greg Friedman, friedman@cognosis.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. Serge Froment wrote:
  9. > >The only property ODF requires all
  10. > >scriptable objects to support is pClass. Some classes of objects can be
  11. > >specified by numeric index, others can't.
  12. >
  13. > The script command "get someProperty of first someClass" has ODF to access
  14. > an object by index. When access index is not supported, we get an error
  15. > message like "Can't make someClass 1 into someClass 1". This message
  16. > confused my into thinking there were an ODF bug. I guess many users will be
  17. > confused too.
  18.  
  19. I took a look at the case you described, and tried a couple of scenarios.
  20. Right now, I don't currently call HasProperty when doing object resolution
  21. by index (including the absolute ordinal values). I'll add some calls to
  22. HasProperty when accessing object by the various indexicals. I'm not sure
  23. how you are getting the specific message you are getting - I suspect it has
  24. something to do with the way you are generating scriptable objects on they
  25. fly from within your iterator. Even though I can't reproduce your error,
  26. there is a good chance that preventing the indexical accessors from working
  27. when explicit support for pIndex isn't present will give users a more
  28. sensible error message. Much of this is moot anyhow, because pIndex should
  29. be supported in almost all cases.
  30.  
  31. > I have another question I posted to the list and get some reply from Chris
  32. > Hunt, but I am still confused. Here is my question:
  33. >
  34. > Since scriptable parts inherit from FW_MPartScriptable (or
  35. > FW_MEmbeddingPartScriptable), it looks like parts can have properties.
  36. > However, I can't figure out how to specify part properties inside the
  37. > 'aete' resource in such way that ODF will call my override of GetProperty
  38. > for the my added property of my part object.
  39.  
  40. All 'aete' resource should contain at least a stub of the 'ODst' suite
  41. defined by OpenDoc. Since you want to extend the part class introduced in
  42. ODst, you should define an 'ODst' suite that includes _only_ the part class
  43. with your extra properties. Do not redefine the existing properties, just
  44. define the properties you are adding. This is documented in "Inside
  45. Macintosh: Interapplication Communication" in the section "Extending the
  46. Standard Suites". One caveat applies: the current version of OpenDoc
  47. collapses all part aete resources into a single namespace. This means that
  48. the properties you define will appear to be properties of the "part" class,
  49. and AppleScript will allow users to compile scripts referencing your
  50. properties against any part editor.
  51.  
  52. Accessing objects or properties of "part" is a special case. OpenDoc
  53. provides a bunch of default accessors that do the right thing for all of
  54. the properties and elements intrisic to the defined part class. When ODF
  55. gets a request for an object contained in "part", it calls the
  56. GetObjectContainedInPart method of FW_MPartScriptable. This is necessary,
  57. to distinguish between object contained by the "null" object, and objects
  58. contained by "part". By default, ODF defers accesses to objects contained
  59. by "part" to the OpenDoc shell. We always handle accesses to objects
  60. contained by the "null" object. In your case, you probably need to handle
  61. the request for a property of part.
  62.  
  63. I just added some code to FW_MPartScriptable::GetObjectContainedInPart that
  64. I think may address your problem.  This method now reads as follows:
  65.  
  66. FW_MScriptable* MPartScriptable::GetObjectContainedInPart(
  67.                 Environment* ev,
  68.                 ODDescType desiredClass,
  69.                 ODDescType form,
  70.                 FW_CDesc& selectionData)
  71. {
  72.     FW_MScriptable* acquiredObject = NULL;
  73.  
  74.     if (desiredClass == cProperty)
  75.     {
  76.         FW_CPart* part = FW_DYNAMIC_CAST(FW_CPart, this);
  77.         FW_ASSERT(part);
  78.         acquiredObject = GetContainedObject(ev,
  79.                     part, desiredClass, form,
  80.                     selectionData);
  81.     }
  82.     return acquiredObject;
  83. }
  84.  
  85. This new code special cases property accesses, and will ultimately cause a
  86. call to HasProperty to be made, and a property designator will be created
  87. if the property is supported.
  88.  
  89. Please try this, and let me know if it fixes your problem.
  90.  
  91. Greg.
  92.  
  93.  
  94. ___________________________________________________________
  95.  Greg Friedman       ODF Engineering        Apple Computer
  96.  
  97.  
  98.